Systems and methods for monitoring vehicle diagnostics

ABSTRACT

Various embodiments provide prognostic vehicle diagnosis methodologies for monitoring the relative health of various vehicle components over time, to enable replacement of those vehicle components prior to component failure. Sensors monitoring those vehicle components transmit generated telematics data to a computing entity configured to generate a telematics data signature based on the sensor-generated data, and to compare the telematics data signature against a reference data signature to ascertain the relative health of the vehicle component. If the telematics data signature satisfies a failure threshold identified within the reference signature, the computing entity initiates a replacement process at least in part by generating an alert for a maintenance personnel.

CLAIM OF PRIORITY

This application, entitled “Systems and Methods for Monitoring VehicleDiagnostics,” claims priority to U.S. Non-Provisional application Ser.No. 15/984,070, entitled “Systems and Methods for Vehicle Diagnostics”filed on May 18, 2018, which claims priority to Provisional PatentApplication No. 62/508,451, filed May 19, 2017, entitled “Systems andMethods for Vehicle Diagnostics,” the entirety of which is incorporatedherein by reference. The subject matter of U.S. patent application Ser.No. 14/667,253 filed Mar. 24, 2015, entitled “Vehicle MaintenanceSystems And Methods” and issued May 17, 2016, as U.S. Pat. No.9,342,933, is related to the subject matter found in this applicationand is also incorporated by reference herein in its entirety.

BACKGROUND

Modern motor vehicles include numerous components that are impracticalto routinely test in order to ensure proper functionality. As a result,many vehicle operators (e.g., individuals and/or companies) simply waituntil such components fail prior to replacing and/or repairing thesecomponents or, alternatively, routinely repair and/or replace thesecomponents according to a preventative maintenance schedule. The formerapproach may result in the failure of the component during vehicle use,which can lead to damage to other vehicle components, substantialinconvenience with respect to retrieval of the incapacitated vehicle,and an increase in the total time the vehicle is out of service. Thelatter approach, however, may result in premature replacement and/orrepair of the components, thereby increasing the lifetime operating costof the vehicle.

Accordingly, a need exists for improved systems and methods fordiagnosing and/or detecting impending vehicle component failures withoutrequiring a significant vehicle owner time expenditure in order toenable replacement and/or repair of vehicle components immediately priorto an impending vehicle component failure.

BRIEF SUMMARY

Prognostic vehicle component monitoring enables preemptive repair and/orreplacement of failing vehicle components identified based on the outputcharacteristics of those vehicle components. Thus, prognostic vehiclecomponent monitoring methodologies incorporate constant or near-constantmonitoring of vehicle component output. The monitored vehicle componentoutput is compared against reference vehicle component data that may beutilized to ascertain the relative health of the vehicle component overan expected component lifetime. Once the monitored vehicle componentoutput satisfies a failing component criteria (such as a thresholdidentified within the reference vehicle component data), a computingentity performing the monitoring initiates a maintenance procedure, suchas by alerting maintenance personnel that a particular vehicle componenton a particular vehicle is failing.

Certain embodiments are directed to prognostic vehicle diagnosticsystems configured for monitoring the relative health of one or morevehicle components. The system may comprise at least one telematicssensor secured within a vehicle and configured to generate telematicsdata based on output of at least one vehicle component; and a computingentity in wireless communication with the vehicle. The computing entitymay be configured to: receive telematics data from the at least onetelematics sensor, wherein the telematics data comprises a plurality oftelematics data points each indicative of the vehicle component output;store the received telematics data within a telematics data file to forma telematics data signature for the at least one vehicle component;retrieve a performance metric comprising a reference data signature forthe at least one vehicle component, wherein the reference data signatureidentifies a threshold component failure level for the vehiclecomponent; compare the telematics data signature and the reference datasignature to determine whether the telematics data signature satisfiesthe threshold component failure level; and upon determining that thetelematics data signature satisfies the threshold component failurelevel, generate an output notification to initialize a repair procedurefor the vehicle component.

The telematics sensor may be a voltage sensor configured to monitor theoutput voltage of a vehicle alternator, the telematics data may comprisealternator output voltage data and the telematics data signature mayidentify the alternator voltage output as a function of time, and thereference data signature may identify a reference alternator voltageoutput as a function of time, and the threshold component failure levelmay identify an alternator output voltage when the reference alternatorfailed. However, in certain embodiments the telematics sensor mat be anitrogen dioxide sensor configured to monitor the nitrogen dioxide levelwithin a vehicle exhaust; the telematics data may comprise nitrogendioxide output level data and the telematics data signature may identifythe nitrogen dioxide output level as a function of time; and thereference data signature may identify a reference nitrogen dioxideoutput level as a function of time, and the threshold component failurelevel may identify a nitrogen dioxide output level when the catalyticconverter failed.

Certain embodiments are directed to methods for prognostic diagnosis ofone or more vehicle components. The method may comprise steps for:generating telematics data via at least one sensor secured within avehicle and configured to monitor the output of a vehicle component,wherein the telematics data comprises a plurality of telematics datapoints each indicative of the vehicle component output; storing, via acomputing entity in wireless communication with the vehicle, thegenerated telematics data within a telematics data file to form atelematics data signature for the at least one vehicle component;retrieving, via the computing entity, a performance metric comprising areference data signature for the at least one vehicle component, whereinthe reference data signature identifies a threshold component failurelevel for the vehicle component; comparing, via the computing entity,the telematics data signature and the reference data signature todetermine whether the telematics data signature satisfies the thresholdcomponent failure level; and upon determining that the telematics datasignature satisfies the threshold component failure level, generating,via the computing entity, an output notification to initialize a repairprocedure for the vehicle component.

In various embodiments, the telematics sensor may be a voltage sensorconfigured to monitor the output voltage of a vehicle alternator, thetelematics data may comprise alternator output voltage data and thetelematics data signature may identify the alternator voltage output asa function of time, and the reference data signature may identify areference alternator voltage output as a function of time, and thethreshold component failure level may identify an alternator outputvoltage when the reference alternator failed. However, in certainembodiments the telematics sensor may be a nitrogen dioxide sensorconfigured to monitor the nitrogen dioxide level within a vehicleexhaust; the telematics data may comprise nitrogen dioxide output leveldata and the telematics data signature may identify the nitrogen dioxideoutput level as a function of time; and the reference data signature mayidentify a reference nitrogen dioxide output level as a function oftime, and the threshold component failure level may identify a nitrogendioxide output level when the catalytic converter failed.

Moreover, various embodiments are directed to a computer program productcomprising at least one non-transitory computer-readable storage mediumhaving computer-readable program code portions stored therein, thecomputer-readable program code portions comprising: an executableportion configured to receive telematics data generated via at least onevehicle sensor secured within a vehicle and configured to monitor theoutput of a vehicle component, wherein the telematics data comprises aplurality of telematics data points each indicative of the vehiclecomponent output; an executable portion configured to store thegenerated telematics data within a telematics data file to form atelematics data signature for the at least one vehicle component; anexecutable portion configured to retrieve a performance metriccomprising a reference data signature for the at least one vehiclecomponent, wherein the reference data signature identifies a thresholdcomponent failure level for the vehicle component; an executable portionconfigured to compare the telematics data signature and the referencedata signature to determine whether the telematics data signaturesatisfies the threshold component failure level; and an executableportion configured to, upon determining that the telematics datasignature satisfies the threshold component failure level, generate anoutput notification to initialize a repair procedure for the vehiclecomponent.

In various embodiments, the telematics sensor may be a voltage sensorconfigured to monitor the output voltage of a vehicle alternator, thetelematics data may comprise alternator output voltage data and thetelematics data signature may identify the alternator voltage output asa function of time, and the reference data signature may identify areference alternator voltage output as a function of time, and thethreshold component failure level may identify an alternator outputvoltage when the reference alternator failed. However, in certainembodiments the telematics sensor may be a nitrogen dioxide sensorconfigured to monitor the nitrogen dioxide level within a vehicleexhaust; the telematics data may comprise nitrogen dioxide output leveldata and the telematics data signature may identify the nitrogen dioxideoutput level as a function of time; and the reference data signature mayidentify a reference nitrogen dioxide output level as a function oftime, and the threshold component failure level may identify a nitrogendioxide output level when the catalytic converter failed.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S)

Reference will now be made to the accompanying drawings, which are notnecessarily drawn to scale, and wherein:

FIG. 1 is a diagram of a system that can be used to practice variousembodiments of the present invention.

FIG. 2 is a flowchart illustrating operations and processes that can beused in accordance with various embodiments of the present invention.

FIG. 3 is an example voltage output indicating a potentially failingvehicle components in accordance with various embodiments of the presentinvention.

FIG. 4 is a diagram of an information/data collection device that may beused in association with certain embodiments of the present invention.

FIG. 5 is a schematic of a central computing entity in accordance withcertain embodiments of the present invention.

FIG. 6 is a schematic of a mobile computing entity in accordance withcertain embodiments of the present invention.

DESCRIPTION

Various embodiments of the present invention now will be described morefully hereinafter with reference to the accompanying drawings, in whichsome, but not all embodiments of the inventions are shown. Indeed, theseinventions may be embodied in many different forms and should not beconstrued as limited to the embodiments set forth herein; rather, theseembodiments are provided so that this disclosure will satisfy applicablelegal requirements. The term “or” is used herein in both the alternativeand conjunctive sense, unless otherwise indicated. The terms“illustrative” and “exemplary” are used to be examples with noindication of quality level. Like numbers refer to like elementsthroughout.

Various embodiments provide systems and methods enabling prognosticvehicle maintenance processes for various vehicles. As discussed herein,prognostic vehicle maintenance may utilize performance data for avehicle component to determine when the vehicle component is likely tofail. As discussed herein, the performance data may be compared againstreference data specific for the vehicle component to estimate an amountof useful component life remaining for the vehicle component. Forexample, the performance data may be compared against reference datarepresentative of the performance data for an equivalent vehiclecomponent over the entire life cycle of the equivalent vehiclecomponent. Thus, based on the comparison between the performance dataand the reference data, various systems may determine the amount ofremaining useful life of the vehicle component before the component islikely to fail.

As just one specific example that will be discussed in greater detailherein, performance data for an alternator may comprise a monitoredoutput voltage for the alternator. The monitored output voltage may becompared against reference data indicative of an output voltage of thealternator over the life cycle of the alternator, which may indicatethat the output voltage of the alternator will likely trend toward overthe life of the alternator before failure. Accordingly, once themonitored output voltage of the alternator is similar to the decreasedoutput voltage of the reference data occurring immediately prior tofailure, the alternator may be replaced, thereby avoiding any down timethat may result from a failed alternator. The prognostic maintenanceprocesses may be performed automatically while the vehicle is inoperation (e.g., while a vehicle is traversing a delivery route) and/ormanually by initializing a vehicle diagnostic process operable via acomputing entity.

The prognostic maintenance processes may be contrasted againstcondition-based maintenance or scheduled preventative maintenance.According to condition-based maintenance, the performance of variousvehicle components are not specifically monitored, and accordinglyvehicle components are serviced (e.g., repaired and/or replaced) afterthe component fails. According to scheduled preventative maintenance,vehicle components are serviced at scheduled intervals (e.g., accordingto predefined time periods and/or according to predefined amounts ofuse), regardless of the actual condition of the vehicle components.

According to various embodiments, systems and methods are provided toenable the identification of one or more vehicle components that arelikely to fail in the near future. In particular, the systems andmethods described herein enable the identification of one or morevehicle components exhibiting detectable symptoms of impending componentfailure, such that appropriate remedial action may be taken. In certainembodiments, the system may additionally instigate the appropriateremedial action by, for example, ensuring that appropriate parts,components, and/or the like are available to a vehicle owner and/orservice center such that the failing vehicle components may be repairedand/or replaced in a timely manner.

According to various embodiments, monitored vehicles include one or morevehicle mounted sensors (e.g., telematics sensors) configured tocollect/capture telematics information/data comprising vehicle componentperformance data for one or more vehicle components. For example, abattery voltage may be monitored over time, an alternator output may bemonitored over time, a starter current may be monitored over time, anengine crank speed (e.g., measured in revolutions per minute (RPM)) maybe monitored over time, exhaust emissions from one or more cylinders maybe monitored over time, and/or the like. The telematics information/datamay be transmitted from the one or more sensors to a computing entity(e.g., a mobile computing entity, an on-board computing entity, acentral computing entity (e.g., external to the vehicle), and/or thelike. Based on the collected/captured and transmitted telematicsinformation/data, the computing entity may identify a vehicle componentfor which the telematics information/data applies, and determines one ormore performance metrics for the vehicle component. As non-limitingexamples, for an alternator, the computing entity may determine that anappropriate performance metric is a threshold value for an outputvoltage. For a spark plug, the computing entity may determine that anappropriate performance metric is a threshold quantity of nitrogendioxide in an exhaust flow from a corresponding cylinder. For a starter,the computing entity may determine than an appropriate performancemetric is the current drawn by the starter.

Moreover, based on the collected/captured telematics information/dataand the identified performance metrics, one or more telematicscharacteristics may be determined. The telematics characteristics maycomprise organized telematics data output (e.g., data output organizedas a function of time), summary telematics data (e.g., moving average,average, median, peak, and/or the like), and/or the like. For example, amoving average output voltage of an alternator may be determined, amoving average quantity of nitrogen dioxide in an exhaust flow may bedetermined, and/or the like.

The determined telematics characteristics may be compared against thedetermined performance metrics to determine whether the telematicscharacteristics satisfy the performance metrics. Upon a determinationthat the telematics characteristics satisfy the applicable performancemetrics, various embodiments may continue to monitor thecollected/captured telematics information/data. Upon a determinationthat the telematics characteristics do not satisfy the applicableperformance metrics, various embodiments may initiate a maintenanceprocedure. For example, various embodiments may order replacement and/orrepair parts to replace and/or repair the failing vehicle component. Invarious embodiments, an alert may be generated to the vehicle owner,vehicle operator, a service technician, a fleet manager, and/or thelike.

In various embodiments, various calculations, determinations,identifications, and/or the like may be performed by and/or inassociation with one or more computing entities and/or computer programproducts. The below “Exemplary System Implementation” section describesvarious components and/or features of exemplary computing entitiesaccording to various embodiments. As just brief examples, such featuresmay be performed by and/or in association with a central computingentity (e.g., a central server), a mobile computing entity (e.g., ahandheld device), and/or the like.

FIG. 1 shows an example component monitoring system implemented formonitoring of components on one or more vehicles. As shown in FIG. 1, avehicle 100 and/or various onboard computing entities (e.g.,information/data collection device 130, telematics sensors 125, locationsensors 120) are in communication with a central computing entity 110and/or a mobile computing entity 105 via one or more wired and/orwireless networks 135. Example components of each of these entities aredescribed in greater detail herein. In various embodiments, dataindicative of the operating condition of a particular vehicle componentmay be generated by one or more onboard sensors of the vehicle 100 andmay be transmitted to one or more mobile computing devices 105 and/or acentral computing device 110 for a determination of whether thecollected performance data is indicative of a potentially failingvehicle component.

I. Exemplary System Operation

Reference will now be made to FIGS. 2-3. FIG. 2 is a flowchartillustrating operations and processes that can be used in accordancewith various embodiments of the present invention. FIG. 3 illustratesexemplary telematics information/data in accordance with variousembodiments of the present invention.

As will be discussed in reference to FIGS. 2 and 3, various embodimentsare directed to systems and methods for identifying failing vehiclecomponents and for initiating a maintenance procedure to replace and/orrepair the same. Accordingly, one or more specifically configuredsensors may be configured to collect/capture telematics information/datafor one or more vehicle components. For example, a battery voltagesensor may be configured to monitor a battery voltage (e.g., an outputvoltage) over time. The battery voltage sensor may be secured across thebattery output terminals (e.g., physically secured relative to thebattery) and/or may be secured within an onboard vehicle electricalcircuit incorporating the battery. As another example, the sensors maycomprise an in-line current sensor secured within at least a portion ofan onboard electrical circuit of a vehicle, and the in-line currentsensor may be configured to monitor the amount of current drawn by astarter (and/or other electrical components operable within thevehicle), and/or the like. Based on telematics information/datacollected/captured by specifically configured sensors in communicationwith an information/data collection device 130 (described in greaterdetail herein), the systems and methods may enable an identification offailing vehicle components before the components become non-operational.For example, sensors specifically configured to monitor an outputvoltage of an alternator, sensors specifically configured to monitor astored voltage of a battery, sensors specifically configured to monitorthe emissions content of an exhaust flow exiting a particular enginecylinder (e.g., having an integrated catalyst positioned within theexhaust flow), sensors specifically configured to monitor an outputvoltage and/or current of a vehicle starter, and/or the like may beutilized to collect/capture telematics information/data from applicablevehicle components.

With reference to FIG. 2, a method for identifying failing vehiclecomponents may begin by collecting/capturing component telematicsinformation/data, as shown in Block 501. As noted herein, the componenttelematics information/data is collected/captured by one or morespecially configured sensors (e.g., voltage sensors, emissions sensors,and/or the like) specifically configured to collect/capture telematicsinformation/data for one or more vehicle components. The sensors may bespecifically configured to interact with corresponding vehiclecomponents, and accordingly the sensors may comprise one or moremounting brackets, electronic control units (ECU), and/or the likespecifically configured such that the sensor may collect/capturetelematics information/data from one or more vehicle components. As aspecific, non-limiting example, a voltage sensor may comprise one ormore ECUs and/or mounting brackets specifically configured such that thevoltage sensor may collect/capture output voltage information/data froma vehicle alternator. The sensors may additionally comprise one or morecommunication interfaces (e.g., wired and/or wireless) configured toenable the sensors to transmit and/or receive electronic data from oneor more computing entities, such as a central computing entity 110, amobile computing entity 105, an information/data collection device 130onboard the vehicle 100, and/or the like. In certain embodiments, thesensors may be in electronic communication with the information/datacollection device 130 via a data bus, such that the sensors mayperiodically and/or continuously transmit information/data to theinformation/data collection device 130, as discussed in greater detailherein.

With reference again to Block 501 of FIG. 2, as a specific example ofcollecting/capturing component telematics information/data, aspecifically configured sensor may collect/capture information/dataindicative of an output voltage of an alternator. As noted herein, thetelematics information/data may be collected/captured periodically,regularly, and/or in response to one or more triggers/events, asdiscussed herein. In various embodiments, the sensor may be incommunication with an onboard storage memory configured to temporarilystore the collected/captured telematics information/data. In variousembodiments, the sensor may be configured to collect/capture a pluralityof information/data points (e.g., over a period of time).

After collecting/capturing the component telematics information/data, invarious embodiments the one or more sensors are configured to transmitthe collected/captured component telematics information/data to acomputing entity (e.g., the information/data collection device 130, themobile computing entity 105, the central computing entity 110, anonboard computing entity, a user computing entity, and/or the like), asshown in Block 502. In various embodiments, the sensors may beconfigured to transmit (e.g., via a wired communication protocol and/ora wireless communication protocol) the collected/captured telematicsinformation/data regularly, periodically, in real time (e.g., as eachinformation/data point is collected/captured), in response to atrigger/event (e.g., upon a determination that the vehicle has returnedto a vehicle hub), and/or the like. In various embodiments, the sensorsmay be configured to transmit the collected/captured telematicsinformation/data via one or more other computing devices. For example,the sensor may be configured to transmit the information/data to anonboard computing device (e.g., the information/data collection device130) and/or a mobile computing device 105 in close proximity to thesensor, and the onboard computing device and/or mobile device 105 may beconfigured to transmit the information/data to a central computingentity 110.

Once the telematics information/data is received by the computing entity(e.g., central computing entity 110), the computing entity compiles thereceived telematics information/data into a telematics data file to forma telematics data signature. The telematics data signature is indicativeof the operating output of the monitored vehicle component, for example,as a function of time.

With reference again to FIG. 2, the method may continue upon a computingdevice (e.g., central computing entity 110) identifying applicableperformance metrics for the collected/captured component telematicsinformation/data, as shown at Block 503. In certain embodiments, theperformance metrics may comprise reference data signatures indicative ofthe performance of a reference component as a function of time. Asdiscussed herein, the reference data signatures may be compared againstthe generated telematics data signatures to ascertain whether themonitored vehicle component is operating as expected. Accordingly, theidentified performance metrics may identify desirable componentoperation (e.g., desired vehicle component output), failing componenttelematics characteristics (e.g., common output characteristics of afailing vehicle component), a vehicle component life-cycle datasignature (e.g., identifying characteristics of a reference vehiclecomponent output throughout the vehicle component life-cycle between amoment the component was new to a moment the vehicle component fails),and/or the like. The performance metrics may identify target desirableand/or undesirable operating ranges, tolerances, thresholds, and/or thelike for various telematics information/data. For example, theperformance metrics may identify a target desirable output voltage for avehicle alternator (e.g., between 10-15 volts). Upon determining that atelematics information/data output received from the vehicle alternatorfalls within the target desirable output voltage range, a computingentity (e.g., central computing entity 110) may determine that thevehicle alternator is operating properly. FIG. 3 illustrates an exampleof a performance metric for an alternator output voltage overlaid withthe actual output voltage of a failing alternator. It should beunderstood that performance metrics may be identified for any of avariety of vehicle components, as discussed in detail herein.

The central computing entity 110 may retrieve applicable performancemetrics for the collected/captured component telematics information/datafrom a storage device accessible to the central computing entity 110(e.g., a database). The applicable performance metrics may be selectedfrom a plurality of predetermined performance metrics (e.g., a liststored in the database), or the performance metrics may be selectedbased on the collected/captured information/data types. For example,upon receipt of the component telematics information/data, the centralcomputing entity 110 may be configured to extract information/data fromthe component telematics information/data indicative of the type oftelematics information/data to be reviewed. For example, the centralcomputing entity 110 may be configured to extract information/dataindicative of the units to be associated with the component telematicsinformation/data, the source sensor from which the telematicsinformation/data was received, and/or the like. Such information/datamay be stored as metadata associated with the component telematicsinformation/data. In certain embodiments, the central computing entity110 may generate an inquiry to be utilized to retrieve a relevantperformance metric based on determined type of telematicsinformation/data to be reviewed. For example, the generated inquiry maybe configured to identify an appropriate performance metric to beutilized to evaluate data presented using the retrieved units, toevaluate data retrieved from a particular sensor type, and/or the like.The central computing entity 110 may utilize the generated inquiry toidentify a matching performance metric (e.g., providing a performancemetric for the type of telematics information/data to be reviewed), andto retrieve the identified matching performance metric for furtheranalysis. For example, each performance metric may be stored withinformation/data that may be utilized to identify a match between aninquiry and the performance metric. As a specific example, eachperformance metric may be stored in association with data identifyingthe types of units that may be reviewed, the type of sensor that may beevaluated, and/or the like.

Moreover, identifying the appropriate performance metrics may compriseidentifying the vehicle component for which the telematicsinformation/data is collected/captured. For example, as discussedherein, the telematics information/data may comprise contextualinformation/data identifying the source component from which thetelematics information/data is collected/captured (e.g., an alternator).Based on the collected/captured telematics information/data, thecomputing entity 110 may be configured to identify appropriateperformance metrics. For example, the central computing entity 110 maybe configured to detect a threshold value for a moving average voltageoutput for an alternator. As yet another example, the central computingentity 110 may be configured to identify a threshold amount of nitrogendioxide found in emissions from a single cylinder (e.g., a minimumamount of nitrogen dioxide).

In various embodiments, the applicable performance metrics may compriseperformance metrics for two or more monitored telematicscharacteristics. For example, the performance metrics for a particularelectrical vehicle component may comprise both an output voltage and acurrent draw for the electrical component. The performance metricsspecific to each of the two or more monitored telematics characteristicsmay be determined independently of one another, such that adetermination that the vehicle component does not satisfy one of thetelematics characteristics is itself indicative of a failing vehiclecomponent. In yet other embodiments, the performance metrics for variousmonitored telematics characteristics may be interdependent, such that arelevant electrical component is not indicated as failing unless thetelematics characteristics do not satisfy each of a plurality of therelevant performance metrics.

Moreover, one or more performance metrics may be applicable fordetermining the relative health of more than one vehicle component. Forexample, a performance metric indicative of a current draw for a vehiclestarter may be indicative of the relative health of both the vehiclestarter and the vehicle battery. Accordingly, in various embodiments,combinations of multiple performance metrics may be utilized todetermine which of a plurality of vehicle components are failing. Forexample, performance metrics relating to a voltage of a battery and acurrent drawn by a vehicle starter may be utilized to determine ifeither of the battery and/or the vehicle starter are currently failing.Following this example, if a battery voltage and a current drawn by astarter are both determined to be indicative a failing vehiclecomponent, the central computing entity 110 may be configured todetermine that only the battery is likely failing, thereby effectivelyattributing improper vehicle starter current draw to the same failingbattery component. However, if the battery voltage is determined tosatisfy applicable performance metrics, but the starter current draw isindicative of a failing vehicle component, the central computing entity110 may be configured to determine the vehicle starter is likelyfailing, but the vehicle battery remains healthy.

With reference again to FIG. 2, the central computing entity 110 may beconfigured to determine one or more telematics characteristics, as shownin Block 504. As discussed herein, telematics characteristics maycomprise organized telematics information/data (e.g., including allcollected telematics information/data), summary telematicsinformation/data (e.g., a moving average), and/or the like. In variousembodiments, the central computing entity 110 may be configured todetermine appropriate types of telematics characteristics based on thecollected/captured telematics information/data and the identifiedappropriate performance metrics. For example, upon a determination thatan appropriate performance metric comprises a threshold average voltageoutput, the central computing entity 110 may be configured to determinea moving average voltage output value based on the collected/capturedtelematics information/data. As yet another example, upon adetermination that an appropriate performance metric comprises a maximumquantity of nitrogen dioxide in an exhaust emission, the centralcomputing entity 110 may be configured to determine an overall maximumdetected quantity of nitrogen dioxide as provided in the performanceinformation/data. In various embodiments, the central computing entity110 may be configured to determine a plurality of telematicscharacteristics based on the telematics information/data.

As shown at Block 505 of FIG. 2, the central computing entity 110 may beconfigured to compare the determined telematics characteristics againstthe identified applicable performance metrics. In various embodiments,the comparison may comprise steps for determining whether the telematicscharacteristics satisfy applicable performance metrics, as shown atBlock 506 of FIG. 5. For example, the comparison may comprise steps fordetermining whether the telematics characteristics satisfy applicableranges, tolerances, thresholds, and/or the like with respect to theapplicable performance metrics. As discussed herein, the performancemetrics may identify desirable performance metrics (in which case thecentral computing entity 110 may be configured to monitor the telematicscharacteristics for deviations away from the desirable performancemetrics) and/or the performance metrics may identify undesirableperformance metrics indicative of a failing vehicle component (in whichcase the central computing entity 110 may be configured to monitor thetelematics characteristics for a match between the telematicscharacteristics and the performance metrics). Upon determining that thetelematics information/data is indicative of a failing vehicle componentbased on the comparison, the central computing entity 110 may beconfigured to take one or more remedial actions, as discussed herein.

With reference to FIG. 3, which illustrates an example diagram comparinga voltage output of a failing alternator and a properly functioningalternator, the central computing entity 110 may be configured tocompare the telematics characteristics of an alternator againstperformance metrics comprising a reference alternator output. Upon anidentification that the telematics characteristics vary substantiallyfrom the reference output (e.g., the telematics characteristics vary bymore than a defined value, the telematics characteristics are outside ofa predefined range, and/or the like), the central computing entity 110may be configured to determine that the telematics characteristics donot satisfy the performance metrics.

Upon a determination that the telematics characteristics satisfy theperformance metrics, the central computing entity 110 may end theprocess (e.g., and generate one or more alerts and/or institute aremedial action upon determining that the telematics characteristicssatisfy undesirable performance metrics, or take no action upondetermining that the telematics characteristics satisfy desirableperformance metrics), or may continue monitoring for newlycollected/captured telematics information/data in order to repeat theprocess. As yet another example, the central computing entity 110 may beconfigured to provide a notification indicating that the telematicsinformation/data indicates that the monitored vehicle components areproperly functioning.

Upon a determination that the telematics characteristics are indicativeof a failing vehicle component (e.g., the telematics characteristics donot satisfy desirable performance metrics and/or the telematicscharacteristics satisfy undesirable performance metrics), the centralcomputing entity 110 may institute one or more remedial actions, such asinstituting one or more maintenance procedures to facilitate repairingand/or replacing the failing vehicle components. For example, thecentral computing entity 110 may generate an alert to be received by oneor more users (e.g., vehicle owners, vehicle operators, servicetechnicians, and/or the like). Accordingly, upon receipt of an alertthat a vehicle component is failing, the users may be notified that thevehicle in question should not be utilized until the vehicle componentis repaired and/or replaced.

In various embodiments, the central computing entity 110 may beconfigured to order one or more replacement parts and/or components inresponse to a determination that a particular vehicle component isfailing. For example, upon a determination that a vehicle alternator isfailing, the central computing entity 110 may be configured toautomatically order a replacement alternator for the vehicle.Accordingly, the central computing entity 110 may be in communicationwith one or more vehicle parts suppliers, such that the centralcomputing entity 110 may convey information/data identifying the neededreplacement parts to the supplier.

a. Information/Data Collection

In one embodiment, appropriate computing entities (e.g., sensors,information/data collection devices 130, and/or the like) cancollect/capture telematics information/data regularly, periodically,continuously, and/or upon determining the occurrence of one or morepredefined triggers/events. In another embodiment, the appropriatecomputing entities can collect/capture telematics information/data inresponse to certain triggers or events. For example, theinformation/data collection device 130 can monitor information/datagenerated by the vehicle sensors (120, 125) for parameters that matchpredefined triggers/events. In one embodiment, the information/datacollection device 130 can monitor some or all the following predefinedevents: (a) the vehicle 100 being turned on and beginning to idle (e.g.,where vehicle sensors 120, 125 indicate the vehicle's engine is turnedon and the vehicle speed is zero); (b) the vehicle 100 beginning to moveand thereby ceasing to idle (e.g., where the vehicle sensors 120, 125indicate the vehicle's engine is on and the vehicle's speed hasincreased from zero to a non-zero value); (c) the vehicle 100 slowing toa stop and beginning to idle (e.g., where the vehicle sensors 120, 125indicate the vehicle's engine is on and the vehicle's speed hasdecreased from a non-zero value to zero); (d) the vehicle 100 beingturned off and ceasing to idle (e.g., where the vehicle sensors 120, 125indicate the vehicle's engine is turned off and the vehicle speed iszero); (e) the vehicle 100 moving out of a geo-fenced area; (f) thevehicle 100 moving into a geo-fenced area; (g) the vehicle 100 movinginto a geo-fenced area associated with a delivery area assigned to thevehicle 100 and/or its driver; (h) the vehicle 100 moving out of ageo-fenced area associated with a delivery area assigned to the vehicle100 and/or its driver; (i) the vehicle 100 beginning to move in areverse direction; (j) the vehicle 100 ceasing to move in a reversedirection; (k) the vehicle's 100 seat belt being engaged or disengagedwhile the vehicle's 100 engine is on; (l) the vehicle 100 beginning tomove in a forward direction; (m) the vehicle 100 ceasing to move in aforward direction; (n) the vehicle 100 traveling above a certain speed;(o) the vehicle 100 being placed in the park position; and/or a varietyof other triggers/events.

If a predefined trigger/event is detected, the information/datacollection device 130 can capture and store telematics information/datafrom the vehicle sensors 120, 125. The telematics information/datacaptured from the sensors 120, 125 may include various types oftelematics information/data, including location information/data. Forexample, the information/data collection device 130 may collect voltagedata for a vehicle alternator each time the vehicle is started. Theinformation/data collection device 130 may link this collectedinformation/data with location information/data for the vehicle 100.Should the information/data collection device determine that a vehiclecomponent has failed such that the vehicle is non-operational, thecollected information/data may be indicative of the current location ofthe vehicle 100 such that the vehicle 100 (and vehicle operator) may beretrieved.

If a predefined trigger/event is not detected, the information/datacollection device 130 can determine whether a threshold information/datacapture time has elapsed. For example, in one embodiment, the thresholdinformation/data capture time can be defined as 30 seconds (or any othertime period). If the information/data collection device 130 determinesthat the threshold information/data capture time has not elapsed, theinformation/data collection device 130 can continue monitoring forpredefined events. However, if the information/data collection device130 determines that the threshold information/data capture time haselapsed (e.g., more than 30 seconds have passed since the last time thatinformation/data was captured from the vehicle sensors), theinformation/data collection device 130 can capture telematicsinformation/data.

In one embodiment, the telematics information/data may includecontextual information/data collected/captured with the telematicsinformation/data. In another embodiment, contextual information/data canbe associated with the collected/captured telematics information/data.The contextual information may comprise metadata associated with thetelematics information/data, and/or other information/data that may beusable to distinguish aspects of the For instance, an appropriatecomputing entity (e.g., mobile computing entity 105) can be configuredto collect/capture some or all of the following contextualinformation/data: (a) the date (e.g., 12/30/2014) and time (e.g., 13:24)the telematics information/data is captured; (b) the driver associatedwith the mobile computing entity 105 at the time the telematicsinformation/data is captured (e.g., James P. Smith); (c) the vehicleassociated with the driver at the time the telematics information/datais captured (e.g., a vehicle identification number such as AS445); (d)the type of telematics information/data captured (e.g., stop status,lunch break); (e) if applicable—a route number and/or stop numberassociated with the input telematics information/data (e.g., stop 3);(f) the serviceable point associated with the telematicsinformation/data captured; (g) the address associated with thetelematics information/data captured; (h) a logged reason for andlocation of the information/data capture (e.g., a code indicating thedetected predefined trigger/event or indicating that the thresholdinformation/data capture time interval elapsed); and/or the like.Further, in one embodiment, an appropriate computing entity (e.g., theinformation/data collection device 130, the central computing entity110, the mobile computing entity 105, and/or the like) can be configuredto associate the captured telematics information/data with thecontextual information/data by, for example, storing fields oftelematics information/data captured from the vehicle sensors 120, 125in the same record, or records, as concurrently captured contextualinformation/data, thereby associating the two types of information/dataif necessary. As discussed herein, such a configuration may enable thesystem to identify the current location of a vehicle, as well as thetype of vehicle and the identity of the driver, upon a determinationthat a particular vehicle component has failed, thereby rendering thevehicle non-operational. This information/data may thus be used todetermine whether to retrieve the vehicle and vehicle operator.Moreover, in certain embodiments, the central computing entity 110 maybe configured to store the telematics information/data withinformation/data indicative of the performance of the vehicle 100 and/orvarious vehicle components. This data may be stored as historicalinformation/data (e.g., in a storage device in association with thecentral computing entity 110). In certain embodiments, the historicalinformation/data may be searchable, such that portions of the historicalinformation/data may be provided to a user, for example, in response toa search query.

Moreover, the central computing entity 110 may be configured to utilizethe historical information/data to update performance metrics to beapplied for future vehicle component monitoring. For example, theperformance metrics may be generated based on historicalinformation/data indicative of an anticipated vehicle component failure.Thus, as the central computing entity 110 generates and storesadditional historical information/data, the performance metrics may beadjusted to reflect known failure points of components, as evidenced inthe historical information/data.

In one embodiment, the information/data collection device 130 cantransmit the captured telematics information/data and/or associatedcontextual information/data to the central computing entity 110 ormobile computing entity 105. This may be accomplished by using any ofthe transmission methods and systems described herein, as well as othermethods, protocols, and systems known in the art. In one embodiment, theinformation/data collection device 130 can be configured to firstattempt to transmit captured information/data to the central computingentity 110, and subsequently attempt to transfer information/data to themobile computing entity 105 if a connection with the central computingentity 110 is unavailable.

In one embodiment, the mobile computing entity 105 can transmit thecaptured telematics information/data and/or associated contextualinformation/data to the central computing entity 110. This may beaccomplished by using any of the transmission methods and systemsdescribed herein, as well as other methods, protocols, and systems knownin the art. In one embodiment, the mobile computing entity 105 can beconfigured to first attempt to transmit captured information/data to thecentral computing entity 110, and subsequently attempt to transferinformation/data to the information/data collection device 130 if aconnection with the central computing entity 110 is unavailable.

II. Exemplary System Implementation

As noted herein, various embodiments of the present invention maycomprise various steps, features, and/or the like that are executed byand/or with a computer program product that comprises articles ofmanufacture. A computer program product may include a non-transitorycomputer-readable storage medium storing applications, programs, programmodules, scripts, source code, program code, object code, byte code,compiled code, interpreted code, machine code, executable instructions,and/or the like (also referred to herein as executable instructions,instructions for execution, program code, and/or similar terms usedherein interchangeably). Such non-transitory computer-readable storagemedia include all computer-readable media (including volatile andnon-volatile media).

In one embodiment, a non-volatile computer-readable storage medium mayinclude a floppy disk, flexible disk, hard disk, solid-state storage(SSS) (e.g., a solid state drive (SSD), solid state card (SSC), solidstate module (SSM)), enterprise flash drive, magnetic tape, or any othernon-transitory magnetic medium, and/or the like. A non-volatilecomputer-readable storage medium may also include a punch card, papertape, optical mark sheet (or any other physical medium with patterns ofholes or other optically recognizable indicia), compact disc read onlymemory (CD-ROM), compact disc-rewritable (CD-RW), digital versatile disc(DVD), Blu-ray disc (BD), any other non-transitory optical medium,and/or the like. Such a non-volatile computer-readable storage mediummay also include read-only memory (ROM), programmable read-only memory(PROM), erasable programmable read-only memory (EPROM), electricallyerasable programmable read-only memory (EEPROM), flash memory (e.g.,Serial, NAND, NOR, and/or the like), multimedia memory cards (MMC),secure digital (SD) memory cards, SmartMedia cards, CompactFlash (CF)cards, Memory Sticks, and/or the like. Further, a non-volatilecomputer-readable storage medium may also include conductive-bridgingrandom access memory (CBRAM), phase-change random access memory (PRAM),ferroelectric random-access memory (FeRAM), non-volatile random-accessmemory (NVRAM), magnetoresistive random-access memory (MRAM), resistiverandom-access memory (RRAM), Silicon-Oxide-Nitride-Oxide-Silicon memory(SONOS), floating junction gate random access memory (FJG RAM),Millipede memory, racetrack memory, and/or the like.

In one embodiment, a volatile computer-readable storage medium mayinclude random access memory (RAM), dynamic random access memory (DRAM),static random access memory (SRAM), fast page mode dynamic random accessmemory (FPM DRAM), extended information/data-out dynamic random accessmemory (EDO DRAM), synchronous dynamic random access memory (SDRAM),double information/data rate synchronous dynamic random access memory(DDR SDRAM), double information/data rate type two synchronous dynamicrandom access memory (DDR2 SDRAM), double information/data rate typethree synchronous dynamic random access memory (DDR3 SDRAM), Rambusdynamic random access memory (RDRAM), Twin Transistor RAM (TTRAM),Thyristor RAM (T-RAM), Zero-capacitor (Z-RAM), Rambus in-line memorymodule (RIMM), dual in-line memory module (DIMM), single in-line memorymodule (SIMM), video random access memory (VRAM), cache memory(including various levels), flash memory, register memory, and/or thelike. It will be appreciated that where embodiments are described to usea computer-readable storage medium, other types of computer-readablestorage media may be substituted for or used in addition to thecomputer-readable storage media described above.

As should be appreciated, various embodiments of the present inventionmay also be implemented as methods, apparatus, systems, computingdevices, computing entities, and/or the like. As such, embodiments ofthe present invention may take the form of an apparatus, system,computing device, computing entity, and/or the like executinginstructions stored on a computer-readable storage medium to performcertain steps or operations. However, embodiments of the presentinvention may also take the form of an entirely hardware embodimentperforming certain steps or operations.

Embodiments of the present invention are described below with referenceto block diagrams and flowchart illustrations. Thus, it should beunderstood that each block of the block diagrams and flowchartillustrations may be implemented in the form of a computer programproduct, an entirely hardware embodiment, a combination of hardware andcomputer program products, and/or apparatus, systems, computing devices,computing entities, and/or the like carrying out instructions,operations, steps, and similar words used interchangeably (e.g., theexecutable instructions, instructions for execution, program code,and/or the like) on a computer-readable storage medium for execution.For example, retrieval, loading, and execution of code may be performedsequentially such that one instruction is retrieved, loaded, andexecuted at a time. In some exemplary embodiments, retrieval, loading,and/or execution may be performed in parallel such that multipleinstructions are retrieved, loaded, and/or executed together. Thus, suchembodiments can produce specifically-configured machines performing thesteps or operations specified in the block diagrams and flowchartillustrations. Accordingly, the block diagrams and flowchartillustrations support various combinations of embodiments for performingthe specified instructions, operations, or steps.

III. Exemplary System Architecture

Referring back to FIG. 1, a system that can be used in conjunction withvarious embodiments of the present invention is illustrated. As shown inFIG. 1, the system may include one or more vehicles 100, one or moremobile computing entities 105, one or more mapping computing entities110, one or more Global Positioning System (GPS) satellites 115, one ormore location sensors 120, one or more telematics sensors 125, one ormore information/data collection devices 130, one or more networks 135,one or more user computing entities (not shown), and/or the like. Eachof the components of the system may be in electronic communication with,for example, one another over the same or different wireless or wirednetworks including, for example, a wired or wireless Personal AreaNetwork (PAN), Local Area Network (LAN), Metropolitan Area Network(MAN), Wide Area Network (WAN), or the like. Additionally, while FIG. 1illustrates certain system entities as separate, standalone entities,the various embodiments are not limited to this particular architecture.

a. Exemplary Vehicle

In various embodiments, the term vehicle 100 is used generically. Forexample, a vehicle 100 may be a manned or an unmanned tractor, truck,car, motorcycle, moped, Segway, bicycle, golf cart, hand truck, cart,trailer, tractor and trailer combination, van, flatbed truck, vehicle,drone, airplane, helicopter, boat, barge, and/or any other form ofobject for moving or transporting people and/or items (e.g., one or morepackages, parcels, bags, containers, loads, crates, items bandedtogether, vehicle parts, pallets, drums, the like, and/or similar wordsused herein interchangeably). In one embodiment, each vehicle 100 may beassociated with a unique vehicle identifier (such as a vehicle ID) thatuniquely identifies the vehicle 100. The unique vehicle ID (e.g.,trailer ID, tractor ID, vehicle ID, and/or the like) may includecharacters, such as numbers, letters, symbols, and/or the like. Forexample, an alphanumeric vehicle ID (e.g., “AS445”) may be associatedwith each vehicle 100. In another embodiment, the unique vehicle ID maybe the license plate, registration number, or other identifyinginformation/data assigned to the vehicle 100.

FIG. 1 shows one or more computing entities, devices, and/or similarwords used herein interchangeably that are associated with the vehicle100, such as an information/data collection device 130 or othercomputing entities. In general, the terms computing entity, entity,device, system, and/or similar words used herein interchangeably mayrefer to, for example, one or more computers, computing entities,desktop computers, mobile phones, tablets, phablets, notebooks, laptops,distributed systems, gaming consoles (e.g., Xbox, Play Station, Wii),watches, glasses, iBeacons, proximity beacons, key fobs, radio frequencyidentification (RFID) tags, ear pieces, scanners, televisions, dongles,cameras, wristbands, wearable items/devices, items/devices, vehicles,kiosks, input terminals, servers or server networks, blades, gateways,switches, processing devices, processing entities, set-top boxes,relays, routers, network access points, base stations, the like, and/orany combination of devices or entities adapted to perform the functions,operations, and/or processes described herein. FIG. 4 provides a blockdiagram of an exemplary information/data collection device 130 that maybe attached, affixed, disposed upon, integrated into, or part of avehicle 100. The information/data collection device 130 may collecttelematics information/data (including location information/data) andtransmit/send the information/data to the mobile computing entity 105,the central computing entity 110, and/or various other computingentities via one of several communication methods.

In one embodiment, the information/data collection device 130 mayinclude, be associated with, or be in wired or wireless communicationwith one or more processors 200 (various exemplary processors aredescribed in greater detail below), one or more location-determiningdevices or one or more location sensors 120 (e.g., Global NavigationSatellite System (GNSS) sensors), one or more telematics sensors 125,one or more real-time clocks 215, a J-Bus protocol architecture, one ormore electronic control modules (ECM) 245, one or more communicationports 230 for receiving telematics information/data from various sensors(e.g., via a CAN-bus), one or more communication ports 205 fortransmitting/sending information/data, one or more RFID tags/sensors250, one or more power sources 220, one or more information/data radios235 for communication with a variety of communication networks, one ormore memory modules 210, and one or more programmable logic controllers(PLC) 225. It should be noted that many of these components may belocated in the vehicle 100 but external to the information/datacollection device 130.

In one embodiment, the one or more location sensors 120, modules, orsimilar words used herein interchangeably may be one of severalcomponents in wired or wireless communication with or available to theinformation/data collection device 130. Moreover, the one or morelocation sensors 120 may be compatible with GPS satellites 115, such asLow Earth Orbit (LEO) satellite systems, Department of Defense (DOD)satellite systems, the European Union Galileo positioning systems, theChinese Compass navigation systems, Indian Regional Navigationalsatellite systems, and/or the like. This information/data can becollected using a variety of coordinate systems, such as the DecimalDegrees (DD); Degrees, Minutes, Seconds (DMS); Universal TransverseMercator (UTM); Universal Polar Stereographic (UPS) coordinate systems;and/or the like. Alternatively, triangulation may be used in connectionwith a device associated with a particular vehicle and/or the vehicle'soperator and with various communication points (e.g., cellular towers orWi-Fi access points) positioned at various locations throughout ageographic area to monitor the location of the vehicle 100 and/or itsoperator. The one or more location sensors 120 may be used to receivelatitude, longitude, altitude, heading or direction, geocode, course,position, time, and/or speed information/data (e.g., referred to hereinas telematics information/data and further described herein below). Theone or more location sensors 120 may also communicate with the centralcomputing entity 110, the information/data collection device 130, mobilecomputing entity 105, and/or similar computing entities.

As indicated, in addition to the one or more location sensors 120, theinformation/data collection device 130 may include and/or be associatedwith one or more telematics sensors 125, modules, and/or similar wordsused herein interchangeably. For example, the telematics sensors 125 mayinclude vehicle sensors, such as engine, fuel, odometer, hubometer, tirepressure, location, weight, emissions, door, and speed sensors. Thetelematics information/data may include, but is not limited to, speedinformation/data, emissions information/data, RPM information/data, tirepressure information/data, oil pressure information/data, seat beltusage information/data, distance information/data, fuelinformation/data, idle information/data, and/or the like (e.g., referredto herein as telematics information/data). The telematics sensors 125may include environmental sensors, such as air quality sensors,temperature sensors, and/or the like. Thus, the telematicsinformation/data may also include carbon monoxide (CO), nitrogen oxides(NOx), sulfur oxides (SOx), Ethylene Oxide (EtO), ozone (O₃), hydrogensulfide (H₂S) and/or ammonium (NH₄) information/data, and/ormeteorological information/data (e.g., referred to herein as telematicsinformation/data).

In one embodiment, the ECM 245 may be one of several components incommunication with and/or available to the information/data collectiondevice 130. The ECM 245, which may be a scalable and subservient deviceto the information/data collection device 130, may have information/dataprocessing capability to decode and store analog and digital inputs fromvehicle systems and sensors. The ECM 245 may further haveinformation/data processing capability to collect and present telematicsinformation/data to the J-Bus (which may allow transmission to theinformation/data collection device 130), and output standard vehiclediagnostic codes when received from a vehicle's J-Bus-compatibleon-board controllers 240 and/or sensors.

As indicated, a communication port 230 may be one of several componentsavailable in the information/data collection device 130 (or be in or asa separate computing entity). Embodiments of the communication port 230may include an Infrared information/data Association (IrDA)communication port, an information/data radio, and/or a serial port. Thecommunication port 230 may receive instructions for the information/datacollection device 130. These instructions may be specific to the vehicle100 in which the information/data collection device 130 is installed,specific to the geographic area in which the vehicle 100 will betraveling, specific to the function the vehicle 100 serves within afleet, and/or the like. In one embodiment, the information/data radio235 may be configured to communicate with a wireless wide area network(WWAN), wireless local area network (WLAN), wireless personal areanetwork (WPAN), or any combination thereof. For example, theinformation/data radio 235 may communicate via various wirelessprotocols, such as 802.11, general packet radio service (GPRS),Universal Mobile Telecommunications System (UMTS), Code DivisionMultiple Access 2000 (CDMA2000), CDMA2000 1X (1xRTT), Wideband CodeDivision Multiple Access (WCDMA), Time Division-Synchronous CodeDivision Multiple Access (TD-SCDMA), Long Term Evolution (LTE), EvolvedUniversal Terrestrial Radio Access Network (E-UTRAN), Evolution-DataOptimized (EVDO), High Speed Packet Access (HSPA), High-Speed DownlinkPacket Access (HSDPA), IEEE 802.11 (Wi-Fi), 802.16 (WiMAX), ultrawideband (UWB), infrared (IR) protocols, Bluetooth protocols (includingBluetooth low energy (BLE)), wireless universal serial bus (USB)protocols, and/or any other wireless protocol.

b. Exemplary Central Computing Entity

FIG. 5 provides a schematic of a central computing entity 110 accordingto one embodiment of the present invention. As indicated, in oneembodiment, the central computing entity 110 may also include one ormore communications interfaces 320 for communicating with variouscomputing entities, such as by communicating information/data, content,information, and/or similar terms used herein interchangeably that canbe transmitted, received, operated on, processed, displayed, stored,and/or the like. For instance, the central computing entity 110 maycommunicate with vehicles 100, mobile computing entities 105, and/or thelike.

As shown in FIG. 5, in one embodiment, the central computing entity 110may include or be in communication with one or more processing elements305 (also referred to as processors, processing circuitry, and/orsimilar terms used herein interchangeably) that communicate with otherelements within the central computing entity 110 via a bus, for example.As will be understood, the processing element 305 may be embodied in anumber of different ways. For example, the processing element 305 may beembodied as one or more complex programmable logic devices (CPLDs),microprocessors, multi-core processors, coprocessing entities,application-specific instruction-set processors (ASIPs), and/orcontrollers. Further, the processing element 305 may be embodied as oneor more other processing devices or circuitry. The term circuitry mayrefer to an entirely hardware embodiment or a combination of hardwareand computer program products. Thus, the processing element 305 may beembodied as integrated circuits, application specific integratedcircuits (ASICs), field programmable gate arrays (FPGAs), programmablelogic arrays (PLAs), hardware accelerators, other circuitry, and/or thelike. As will therefore be understood, the processing element 305 may beconfigured for a particular use or configured to execute instructionsstored in volatile or non-volatile media or otherwise accessible to theprocessing element 305. As such, whether configured by hardware orcomputer program products, or by a combination thereof, the processingelement 305 may be capable of performing steps or operations accordingto embodiments of the present invention when configured accordingly.

In one embodiment, the central computing entity 110 may further includeor be in communication with non-volatile media (also referred to asnon-volatile storage, memory, memory storage, memory circuitry and/orsimilar terms used herein interchangeably). In one embodiment, thenon-volatile storage or memory may include one or more non-volatilestorage or memory media 310 as described above, such as hard disks, ROM,PROM, EPROM, EEPROM, flash memory, MMCs, SD memory cards, Memory Sticks,CBRAM, PRAM, FeRAM, RRAM, SONOS, racetrack memory, and/or the like. Aswill be recognized, the non-volatile storage or memory media may storeinformation/databases, information/database instances,information/database management system entities, information/data,applications, programs, program modules, scripts, source code, objectcode, byte code, compiled code, interpreted code, machine code,executable instructions, and/or the like. The term information/database,information/database instance, information/database management systementity, and/or similar terms used herein interchangeably may refer to astructured collection of records or information/data that is stored in acomputer-readable storage medium, such as via a relationalinformation/database, hierarchical information/database, and/or networkinformation/database.

In one embodiment, the central computing entity 110 may further includeor be in communication with volatile media (also referred to as volatilestorage, memory, memory storage, memory circuitry and/or similar termsused herein interchangeably). In one embodiment, the volatile storage ormemory may also include one or more volatile storage or memory media 315as described above, such as RAM, DRAM, SRAM, FPM DRAM, EDO DRAM, SDRAM,DDR SDRAM, DDR2 SDRAM, DDR3 SDRAM, RDRAM, RIMM, DIMM, SIMM, VRAM, cachememory, register memory, and/or the like. As will be recognized, thevolatile storage or memory media may be used to store at least portionsof the information/databases, information/database instances,information/database management system entities, information/data,applications, programs, program modules, scripts, source code, objectcode, byte code, compiled code, interpreted code, machine code,executable instructions, and/or the like being executed by, for example,the processing element 305. Thus, the information/databases,information/database instances, information/database management systementities, information/data, applications, programs, program modules,scripts, source code, object code, byte code, compiled code, interpretedcode, machine code, executable instructions, and/or the like may be usedto control certain aspects of the operation of the central computingentity 110 with the assistance of the processing element 305 andoperating system.

As indicated, in one embodiment, the central computing entity 110 mayalso include one or more communications interfaces 320 for communicatingwith various computing entities, such as by communicatinginformation/data, content, information, and/or similar terms used hereininterchangeably that can be transmitted, received, operated on,processed, displayed, stored, and/or the like. For instance, the centralcomputing entity 110 may communicate with computing entities orcommunication interfaces of the vehicle 100, mobile computing entities105, and/or the like.

Such communication may be executed using a wired information/datatransmission protocol, such as fiber distributed information/datainterface (FDDI), digital subscriber line (DSL), Ethernet, asynchronoustransfer mode (ATM), frame relay, information/data over cable serviceinterface specification (DOCSIS), or any other wired transmissionprotocol. Similarly, the central computing entity 110 may be configuredto communicate via wireless external communication networks using any ofa variety of protocols, such as GPRS, UMTS, CDMA2000, 1xRTT, WCDMA,TD-SCDMA, LTE, E-UTRAN, EVDO, HSPA, HSDPA, Wi-Fi, WiMAX, UWB, IRprotocols, Bluetooth protocols, USB protocols, and/or any other wirelessprotocol. Although not shown, the central computing entity 110 mayinclude or be in communication with one or more input elements, such asa keyboard input, a mouse input, a touch screen/display input, audioinput, pointing device input, joystick input, keypad input, and/or thelike. The central computing entity 110 may also include or be incommunication with one or more output elements (not shown), such asaudio output, video output, screen/display output, motion output,movement output, and/or the like.

As will be appreciated, one or more of the central computing entity's110 components may be located remotely from other central computingentity 110 components, such as in a distributed system. Furthermore, oneor more of the components may be combined and additional componentsperforming functions described herein may be included in the centralcomputing entity 110. Thus, the central computing entity 110 can beadapted to accommodate a variety of needs and circumstances.

c. Exemplary Mobile Computing Entity

FIG. 6 provides an illustrative schematic representative of a mobilecomputing entity 105 that can be used in conjunction with embodiments ofthe present invention. In one embodiment, the mobile computing entities105 may include one or more components that are functionally similar tothose of the central computing entity 110 and/or as described below. Aswill be recognized, mobile computing entities 105 can be operated byvarious parties, including operators of vehicles 100. As shown in FIG.6, a mobile computing entity 105 can include an antenna 412, atransmitter 404 (e.g., radio), a receiver 406 (e.g., radio), and aprocessing element 408 that provides signals to and receives signalsfrom the transmitter 404 and receiver 406, respectively.

The signals provided to and received from the transmitter 404 and thereceiver 406, respectively, may include signaling information/data inaccordance with an air interface standard of applicable wireless systemsto communicate with various entities, such as vehicles 100, centralcomputing entities 110, and/or the like. In this regard, the mobilecomputing entity 105 may be capable of operating with one or more airinterface standards, communication protocols, modulation types, andaccess types. More particularly, the mobile computing entity 105 mayoperate in accordance with any of a number of wireless communicationstandards and protocols. In a particular embodiment, the mobilecomputing entity 105 may operate in accordance with multiple wirelesscommunication standards and protocols, such as GPRS, UMTS, CDMA2000,1xRTT, WCDMA, TD-SCDMA, LTE, E-UTRAN, EVDO, HSPA, HSDPA, Wi-Fi, WiMAX,UWB, IR protocols, Bluetooth protocols, USB protocols, and/or any otherwireless protocol.

Via these communication standards and protocols, the mobile computingentity 105 can communicate with various other entities using conceptssuch as Unstructured Supplementary Service information/data (USSD),Short Message Service (SMS), Multimedia Messaging Service (MMS),Dual-Tone Multi-Frequency Signaling (DTMF), and/or Subscriber IdentityModule Dialer (SIM dialer). The mobile computing entity 105 can alsodownload changes, add-ons, and updates, for instance, to its firmware,software (e.g., including executable instructions, applications, programmodules), and operating system.

According to one embodiment, the mobile computing entity 105 may includelocation determining aspects, devices, modules, functionalities, and/orsimilar words used herein interchangeably. For example, the mobilecomputing entity 105 may include outdoor positioning aspects, such as alocation module adapted to acquire, for example, latitude, longitude,altitude, geocode, course, direction, heading, speed, UTC, date, and/orvarious other information/data. In one embodiment, the location modulecan acquire information/data, sometimes known as ephemerisinformation/data, by identifying the number of satellites in view andthe relative positions of those satellites. The satellites may be avariety of different satellites, including LEO satellite systems, DODsatellite systems, the European Union Galileo positioning systems, theChinese Compass navigation systems, Indian Regional Navigationalsatellite systems, and/or the like. Alternatively, the locationinformation/data may be determined by triangulating the mobile computingentity's 105 position in connection with a variety of other systems,including cellular towers, Wi-Fi access points, and/or the like.Similarly, the mobile computing entity 105 may include indoorpositioning aspects, such as a location module adapted to acquire, forexample, latitude, longitude, altitude, geocode, course, direction,heading, speed, time, date, and/or various other information/data. Someof the indoor aspects may use various position or location technologiesincluding RFID tags, indoor beacons or transmitters, Wi-Fi accesspoints, cellular towers, nearby computing devices (e.g., smartphones,laptops) and/or the like. For instance, such technologies may includeiBeacons, Gimbal proximity beacons, BLE transmitters, Near FieldCommunication (NFC) transmitters, and/or the like. These indoorpositioning aspects can be used in a variety of settings to determinethe location of someone or something to within inches or centimeters.

The mobile computing entity 105 may also comprise a user interface (thatcan include a display 416 coupled to a processing element 408) and/or auser input interface (coupled to a processing element 408). For example,the user interface may be an application, browser, user interface,dashboard, webpage, and/or similar words used herein interchangeablyexecuting on and/or accessible via the mobile computing entity 105 tointeract with and/or cause display of information. The user inputinterface can comprise any of a number of devices allowing the mobilecomputing entity 105 to receive information/data, such as a keypad 418(hard or soft), a touch display, voice/speech or motion interfaces,scanners, readers, or other input device. In embodiments including akeypad 418, the keypad 418 can include (or cause display of) theconventional numeric (0-9) and related keys (#, *), and other keys usedfor operating the mobile computing entity 105 and may include a full setof alphabetic keys or set of keys that may be activated to provide afull set of alphanumeric keys. In addition to providing input, the userinput interface can be used, for example, to activate or deactivatecertain functions, such as screen savers and/or sleep modes. Throughsuch inputs the mobile computing entity can collect contextualinformation/data as part of the telematics information/data.

The mobile computing entity 105 can also include volatile storage ormemory 422 and/or non-volatile storage or memory 424, which can beembedded and/or may be removable. For example, the non-volatile memorymay be ROM, PROM, EPROM, EEPROM, flash memory, MMCs, SD memory cards,Memory Sticks, CBRAM, PRAM, FeRAM, RRAM, SONOS, racetrack memory, and/orthe like. The volatile memory may be RAM, DRAM, SRAM, FPM DRAM, EDODRAM, SDRAM, DDR SDRAM, DDR2 SDRAM, DDR3 SDRAM, RDRAM, RIMM, DIMM, SIMM,VRAM, cache memory, register memory, and/or the like. The volatile andnon-volatile storage or memory can store information/databases,information/database instances, information/database management systementities, information/data, applications, programs, program modules,scripts, source code, object code, byte code, compiled code, interpretedcode, machine code, executable instructions, and/or the like toimplement the functions of the mobile computing entity 105.

d. Exemplary User Computing Entity

In one embodiment, the user computing entities may each include one ormore components that are functionally similar to those of the centralcomputing entity 110 and/or the mobile computing entity 105. Forexample, in one embodiment, each of the user computing entities mayinclude: (1) a processing element that communicates with other elementsvia a system interface or bus; (2) a user interface; (3) transitory andnon-transitory memory; and (4) a communications interface. As previouslynoted, the user computing entity may comprise a user interface. Forexample, the user interface may be an application, browser, userinterface, dashboard, webpage, and/or similar words used hereininterchangeably executing on and/or accessible via the user computingentity to interact with and/or cause display of information/data fromthe central computing entity 110 and/or the mobile computing entity 105,as described herein. These architectures are provided for exemplarypurposes only and are not limiting to the various embodiments.

IV. Conclusion

Many modifications and other embodiments of the inventions set forthherein will come to mind to one skilled in the art to which theseinventions pertain having the benefit of the teachings presented in theforegoing descriptions and the associated drawings. Therefore, it is tobe understood that the inventions are not to be limited to the specificembodiments disclosed and that modifications and other embodiments areintended to be included within the scope of the appended claims.Although specific terms are employed herein, they are used in a genericand descriptive sense only and not for purposes of limitation.

That which is claimed:
 1. A prognostic vehicle diagnostic systemconfigured for monitoring the relative health of one or more vehiclecomponents, the system comprising: at least one voltage sensor securedwithin a vehicle and configured to monitor a voltage output of one ormore vehicle electrical components and generate telematics data based onthe voltage output of the one or more vehicle electrical components; anda computing entity in wireless communication with the vehicle, thecomputing entity configured to: receive telematics data from the atleast one voltage sensor, wherein the telematics data comprises aplurality of telematics data points each indicative of the voltageoutput of the one or more vehicle electrical components; store thereceived telematics data within a telematics data file to form atelematics data signature for the one or more vehicle electricalcomponents; generate an inquiry to identify at least one predeterminedperformance metric for one or more types of telematics data to beretrieved, wherein the at least one predetermined metric comprisesdetecting a threshold value for a moving average voltage output for theone or more vehicle electrical components; retrieve the at least oneidentified predetermined performance metric comprising the thresholdvalue for the moving average voltage output and a reference datasignature for the one or more vehicle electrical components that isindicative of how the one or more vehicle electrical components performsas a function of time, wherein the reference data signature identifies athreshold vehicle electrical failure level for the one or more vehicleelectrical components and wherein the at least one identifiedpredetermined performance metric identifies one or more of desiredvehicle electrical component output, failing vehicle electric componenttelematics characteristics, and vehicle component life-cycle datasignature; compare the telematics data signature and the reference datasignature to determine whether the telematics data signature satisfiesthe threshold vehicle electrical component failure level; and upondetermining that the telematics data signature satisfies the thresholdvehicle electrical component failure level, generate an outputnotification to initialize a repair procedure for the vehicle electricalcomponent.
 2. The prognostic vehicle diagnostic system of claim 1,wherein the telematics data signature identifies the voltage output ofthe vehicle electrical component as a function of time.
 3. Theprognostic vehicle diagnostic system of claim 1, wherein the vehicleelectrical component is one of an alternator, a battery or a starter. 4.The prognostic vehicle diagnostic system of claim 3, wherein theperformance metric of the vehicle electrical component comprises both anoutput voltage and a current draw for the vehicle electrical component.5. The prognostic vehicle diagnostic system of claim 1, wherein thecomputing entity is further configured to generate derivative telematicsdata characteristics of the telematics data signature; and wherein thereference data signature comprises derivative reference datacharacteristics; and comparing the telematics data signature with thereference data signature comprises comparing the derivative telematicsdata characteristics with the derivative reference data characteristics.6. The prognostic vehicle diagnostic system of claim 5, wherein thederivative telematics data characteristics comprises a moving average ofthe telematics data signature.
 7. The prognostic vehicle diagnosticsystem of claim 1, wherein the threshold vehicle electrical componentfailure level identifies a failure range of telematics data valuesindicative of a failing vehicle electrical component.
 8. A prognosticvehicle diagnostic system configured for monitoring the relative healthof a vehicle battery, the system comprising: at least one voltage sensorsecured within a vehicle and configured to monitor a voltage output of avehicle battery and generate telematics data based on the voltage outputof the vehicle battery; and a computing entity in wireless communicationwith the vehicle, the computing entity configured to: receive telematicsdata from the at least one voltage sensor, wherein the telematics datacomprises a plurality of telematics data points each indicative of thevoltage output of the vehicle battery; store the received telematicsdata within a telematics data file to form a telematics data signaturefor the vehicle battery; generate an inquiry to identify at least onepredetermined performance metric for one or more types of telematicsdata to be retrieved, wherein the at least one predetermined metriccomprises detecting a threshold value for an average voltage output forthe vehicle battery; retrieve the at least one identified predeterminedperformance metric comprising the threshold value for the averagevoltage output for the vehicle battery and a reference data signaturefor the vehicle battery that is indicative of how the vehicle batteryperforms as a function of time, wherein the reference data signatureidentifies a threshold vehicle electrical failure level for the vehiclebattery and wherein the at least one identified predeterminedperformance metric identifies one or more of desired battery output,failing vehicle battery telematics characteristics, and vehiclecomponent life-cycle data signature; compare the telematics datasignature and the reference data signature to determine whether thetelematics data signature satisfies the threshold vehicle batteryfailure level; and upon determining that the telematics data signaturesatisfies the threshold vehicle battery failure level, generate anoutput notification to initialize a repair procedure for the vehiclebattery.
 9. The prognostic vehicle diagnostic system of claim 8, whereinthe telematics data signature identifies the voltage output of thevehicle battery as a function of time.
 10. The prognostic vehiclediagnostic system of claim 8, wherein the computing entity is furtherconfigured to generate derivative telematics data characteristics of thetelematics data signature; and wherein the reference data signaturecomprises derivative reference data characteristics; and comparing thetelematics data signature with the reference data signature comprisescomparing the derivative telematics data characteristics with thederivative reference data characteristics.
 11. The prognostic vehiclediagnostic system of claim 10, wherein the derivative telematics datacharacteristics comprises a moving average of the telematics datasignature.
 12. The prognostic vehicle diagnostic system of claim 8,wherein the threshold vehicle battery failure level identifies a failurerange of telematics data values indicative of a failing vehicle battery.13. The prognostic vehicle diagnostic system of claim 8, wherein thesystem generates an alert to a user indicating that the vehicle batteryis failing and that the vehicle should not be utilized until the repairprocedure for the vehicle battery has been completed.
 14. The prognosticvehicle diagnostic system of claim 8, wherein the performance metric ofthe vehicle battery comprises both an output voltage and a current drawfor the vehicle battery.
 15. A computer program product comprising atleast one non-transitory computer-readable storage medium havingcomputer-readable program code portions stored therein, thecomputer-readable program code portions comprising: an executableportion configured to receive telematics data generated via at least onevoltage sensor secured within a vehicle and configured to monitor thestarter current of a vehicle starter, wherein the telematics datacomprises a plurality of telematics data points each indicative ofstarter current of the vehicle starter; an executable portion configuredto store the generated telematics data within a telematics data file toform a telematics data signature for the vehicle starter; an executableportion configured to generate an inquiry to identify at least onepredetermined performance metric for one or more types of telematicsdata to be retrieved, wherein the at least one predetermined metriccomprises detecting a threshold value for an average starter current forthe vehicle starter; an executable portion configured to retrieve atleast one performance metric comprising the threshold value for theaverage starter current for the vehicle starter and a reference datasignature for the vehicle alternator that is indicative of theperformance of the vehicle starter as a function of time, wherein thereference data signature identifies a threshold vehicle starter failurelevel for the vehicle starter and wherein the at least one identifiedpredetermined performance metric identifies one or more of desiredstarter current, failing starter telematics characteristics, and vehiclecomponent life-cycle data signature; an executable portion configured tocompare the telematics data signature and the reference data signatureto determine whether the telematics data signature satisfies thethreshold vehicle starter failure level; and an executable portionconfigured to, upon determining that the telematics data signaturesatisfies the threshold vehicle failure level, generate an outputnotification to initialize a repair procedure for the vehicle starter.16. The computer program product of claim 15, wherein the thresholdvehicle starter failure level identifies the voltage output of thevehicle starter when the vehicle starter has failed.
 17. The computerprogram product of claim 15, further comprising an executable portionconfigured to generate derivative telematics data characteristics of thetelematics data signature; and wherein the reference data signaturecomprises derivative reference data characteristics; and comparing thetelematics data signature with the reference data signature comprisescomparing the derivative telematics data characteristics with thederivative reference data characteristics.
 18. The computer programproduct of claim 17, wherein the derivative telematics datacharacteristics comprises a moving average of the telematics datasignature.
 19. The computer program product of claim 15, wherein thethreshold component failure level identifies a failure range oftelematics data values indicative of a failing voltage starter.
 20. Thecomputer program product of claim 15, further comprising an executableportion configured to generate an alert to a user indicating the vehiclestarter has failed and the vehicle should not be utilized until therepair procedure for the vehicle starter has been completed.